home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-3160 / misc / dischack.txt < prev    next >
Text File  |  1987-04-21  |  5KB  |  105 lines
  1. An interesting little article that gives a few tips on custom 
  2. formatting and the like. It relates to the use of The Gnome 
  3. Services' Analyser utility...but there are plenty of ST utilities 
  4. that can do the sort of things discussed here.
  5.                                                
  6.  
  7. This section has nothing to do with  "yer actual software piracy",
  8. but might prove interesting for the budding hacker.....
  9.  
  10.  
  11. If by now you've used the Analyser on a few Games  disks,  because 
  12. they seem to be the ones with the most aggro for honest hackers, I 
  13. bet  you're puzzled at some of what  you've  seen.  Well,  without 
  14. giving away any secrets, no specific disks, etc, let's just talk a 
  15. bit  about  what we could do to PROTECT a disk  from  those  nasty 
  16. pirates.............     or  even someone who's bought a disk  and 
  17. can't  use  it without always shoving the original in  drive  B  - 
  18. probably the largest cause of hacking to date. 
  19.  
  20. The first thing to do is to format a disk with more than 9 sectors 
  21. per track,  this is assuming a 512 byte sector of course -  simple 
  22. and probably old hat by now, but it catches out GEM.
  23.  
  24. In a similar vein,  the good old ST uses 80 tracks - 0 to 79 -  so 
  25. if we format a disk with 81,  then poor old GEM can't copy it. Bit 
  26. naughty  that one - you are assuming everyones' drive  will  reach 
  27. the 81st track.......
  28.  
  29.  
  30. Before  we  get a bit deeper,  here's one that you can  easily  do 
  31. yourself...     go and hide a file on the disk. How ? Well, have a 
  32. look at the Hacking.doc for a few more hints,  but by changing the 
  33. file attribute you can make it invisible to the desktop. Of course 
  34. this  means you can't load it by clicking on it with the  mouse  - 
  35. have to see it first,  don't you ? BUT, you can still load it from 
  36. within another of your programmes........    go on, have a go !
  37.  
  38.  
  39. We  can  be a bit more devious - the WD1772,   which is  the  chip 
  40. controlling your Atari drives, will write sectors of 128,256,512 & 
  41. 1024  bytes long - but GEM can't cope with 1024 byte  sectors.  In 
  42. fact it normally doesn't use anything but 512 byte sectors.  So we 
  43. can upset the operating system quite well by writing out some 1024 
  44. byte sectors,  or even the 256 byte sectors if we want to.  Or  we 
  45. can  be  really devious and write a track which has a  mixture  or 
  46. 256, 512 & 1024 byte sectors on it - which will confuse the simple 
  47. copiers.......
  48.  
  49. While we're talking about sectors, we don't have to start off with 
  50. a  sector  ID  number  of 1 you know.  No  reason  why  our  track 
  51. shouldn't start off with sector 10, then go to 11,12,13,etc....
  52. Really  beggars up your operating system if you try to copy it  as 
  53. well......
  54.  
  55. Another thing to bear in mind is that if sector ID numbers are out 
  56. of  sequence,  it is likely that the operating system  won't  find 
  57. them  -  neither  will most Disk monitors based  on  the  orthodox 
  58. operating  system. What do I mean ?   
  59.  
  60. Well,  if you had a sequence of 1,2,3,5,6,7 then GEM would stop at 
  61. sector  3 - because it would expect to find a sector 4 and  if  it 
  62. couldn't  find one,  than it terminates the command with an error. 
  63. So you could hide something quite handy in sectors 5,6 & 7.
  64.  
  65.  
  66. Along with the actual sector ID number,  we could put a  different 
  67. track number in the Sector ID field.  Why  ?  Well,  under GEM the 
  68. track & sector number are tested before a sector is loaded. If the 
  69. track  number is different from the track register logged  by  the 
  70. WD1772,  then we have another error,  don't we folks ?  And  guess 
  71. what happens - it doesn't load !
  72.  
  73. A real nasty one is to send out sector or track numbers above 240, 
  74. or anything with $F0  as a hex number.  Now this is sneaky because 
  75. bytes above $F0 are treated as control  bytes by the WD1772 and it 
  76. means  a  custom format routine to duplicate this. 
  77.  
  78. What else can we do ?  Well,  we can write out sector IDs  without 
  79. actually putting a sector there, can't we ? Yes, of course we can. 
  80. Then  when you try to copy the disk you write out a  sector  where 
  81. one  doesn't  really exist on the original  - now  that  would  be 
  82. silly. In fact you could arrange the dummy ID field so that if you 
  83. tried  to write to it,  the data area you created  actually  wrote 
  84. over a VALID sector ID field,  and hence the rest of the track was 
  85. corrupted......
  86.  
  87. Up to now,  we have assumed that we are actually going to format a 
  88. track with sectors.  Don't have to you know.  We can quite  easily 
  89. NOT  format a track in the middle of a disk,  and then  after  the 
  90. programme  has  loaded,  check  the track to see if  it  has  been 
  91. formatted. Got to stop those nasty hackers somehow.
  92.  
  93. In fact,  we don't even have to send out sectors in order to  read 
  94. information from a disk - we could just send out a few sync  bytes 
  95. and then a data mark.  Ok,  the data stands a fair chance of being 
  96. corrupted  but  you  can  generally get the first  5  or  6  bytes 
  97. reliably - enough for a registration mark.
  98.  
  99.  
  100. Well,  now  most  of  these methods are becoming  a  bit  old  hat 
  101. nowadays, but they do keep cropping up.......
  102.  
  103.  
  104.  
  105.